Electronic mail (email) has become the communication method of choice throughout the business world as well as for the general public. In a typical enterprise environment, a mail server (e.g., UNIX SendMail) has a local mail delivery agent or client (typically . . . /bin/mail on UNIX systems) that stores an incoming email on a local file system and delivers it to an end user via Post Office Protocol (POP3), Internet Message Access Protocol (IMAP) or a command line program. Such agents typically provide the basic functionality of logging in an email message and copying that message to a client machine's mail spool. Internet-based client-server messaging systems include, for example, Mozilla Thunderbird™, Microsoft Outlook™, Pegasus™, and Eudora™, which provide email, contact management, calendaring, group scheduling, Web access, task list management, and information management, integrated in an easy-to-use and customizable environment.
The rapid increase in the number of users of the internet has made email an attractive advertising medium. Unfortunately, however, email is now frequently used as the medium for widespread marketing broadcasts of messages to a large number of email addresses. Large service providers and corporations are particularly susceptible to this practice, which is commonly known as spamming, or the sending of unsolicited bulk email (UBE), commonly called spam. The economic cost associated with the sending of UBE is massive. First, it is estimated that 40% of all internet traffic in the United States is UBE. Companies expend considerable time and money removing UBE from their mail servers, purchasing software to filter it, and employing a variety of other techniques to defeat it. By some estimates UBE costs corporations over $10 billion dollars a year to control. (See Spam's Cost To Business Escalates: Bulk Email Threatens Communication Arteries, Johnathan Krim, Washington Post, Mar. 13, 2003 at A01.)
The desire to reduce spam has led to both regulatory and technical solutions. Several states have passed legislation that ban the practice of sending spam email and impose criminal sanctions for violations. (See e.g., Rev. Code of Wa. 19.190.020; CAN-SPAM ACT of 2003, 15 U.S.C. §§7701-13; 18 U.S.C. § 1037.) Technical solutions include a number of techniques. The most common one is to filter UBE by blocking emails from particular email addresses that originate such messages. This approach, however, is vulnerable to rapid changes to the source of the UBE (e.g., changes to the “From” field in the email header), which is relatively easy because most spam is generated by automated means. Such approaches also typically require the set up and maintenance of a complex filtering mechanism.
In order to understand the technological solution to UBE, it is first necessary to understand the technology utilized in the sending and receiving of email. UBE at root exploits some of the technological loopholes associated with the sending and retrieval of email. Most email systems that send email over the internet use the Simple Mail Transfer Protocol (SMTP) to send messages from one server to another; the messages can then be retrieved with an email client using either the aforementioned POP3 or IMAP. In addition, SMTP is generally used to send messages from a mail client to a mail server. This is why is it important that one specify both POP3 or IMAP and the SMTP server when one configures one's email client-server messaging systems. SMTP, POP3 and IMAP reside at the application layer of the TCP/IP protocol stack.
Senders of UBE (Spammers) typically exploit the fact that the SMTP does not always validate or verify the identity of the sender of email (the loophole). Specifically, while the receiver of email is verified by one of many applications residing at the application layer of the TCP/IP protocol stack, the identity of the actual sender is rarely verified. Put another way, SMTP can only verify the sender if it knows the sender to begin with; for example, in the case where a person has a mailbox account housed within the SMTP server. As a result, senders of UBE are free to put whatever name they see fit in the sender or “From” field of an email header and are free to impersonate whomever they so choose. (See RFC 2822 (outlining the header line requirements for an email).) SMTP is one of the most widely used, if not the most widely used, protocol relied upon when sending email. Accordingly, the inability of SMTP to reliably and consistently verify the identity of the sender of email is a loophole that is exploited on a massive scale by those sending UBLE.
Spammers exploit the above-described loophole through a variety of techniques. For example, spammers may use a program called an alpha-numerical generator to create random versions of the local portion of an email address. (See RFC 2822 (outlining the form and parts of an email address).) These random local portions are then paired with a domain name and used to fill the “From” field of the UBE. Another method employed by spammers is to employ address harvesting (Trolling) programs that sift or sniff through streams of data, such as, but not limited to, web pages looking for the “@” symbol followed by “.com” or some other high-level domain extension. Once found, these valid email addresses are captured and used to fill the “From” field of UBE. Still other spammers may just leave the “From” field blank. Finally, some spammers simply set up their own SMTP server and send bulk email unencumbered. This is because SMTP has no method to indicate a sender has been verified, and no method to indicate a sender is known to the recipient of the email.
Various solutions have been devised to deal with UBE. One solution is to devise smart filters that analyze the text and/or subject headings of an email, looking for certain key words, and based upon the probability that these words would occur in an email that is UBE, rejecting or filtering such emails. (See U.S. Pat. No. 6,769,016 B2 (“the Rothwell et al. Patent”).) Another solution is to force the sender of an email to solve a trivial computational puzzle prior to being allowed to send email to a particular mail server. (See U.S. patent application Ser. No. 10/684,020 (Publication No. US 2004/0181571A1) (“the Atkinson et al. Application”).) This computational puzzle may take the form of the sender having to type in the text from an image displayed to them. Still another solution is to require that a sender pay a small fee (e.g., a penny) for each email they send. Such a fee would provide an economic disincentive to the spammer who sends out several million pieces of UBE. Another solution would require the sender's computer to solve some computational puzzle such as factoring a large number using a large amount of computer processing time which would add up to a prohibitive amount of process time for large bulk email operations. One other solution is to require that all emails be associated with or mapped to some particular mail server (an Authorized Server), such that email purportedly coming from a domain would have to be validated by determining if the email did in fact come from an Authorized server for that domain. Still another solution is to create a list of accepted and non-accepted senders of email, and to compare the incoming email against this list. (See U.S. Pat. No. 6,868,498 B1 (“the Katsikas Patent”).)
Another solution to the problem of UBE is to use encryption, and in particular digital signatures, to verify the identity of the sender of email. Yahoo! Inc. proposes a system called a Domain-based email Authentication Using Encryption Public-Keys Advertised in the DNS (DomainKeys). Under the DomainKeys system, public key/private key encryption is used in the form of a digital signature included in the header of the email. (See RSA & Public Key Cryptography, Richard A. Mollin, CRC Press 2002.) In particular, this digital signature is a private encryption key that is included with the email. Once a recipient receives such an email, they query a domain name server (DNS) containing the corresponding public key. This public key is used to verify the identity of the sender of the email. Of note is the fact that the DomainKey system does not modify the “From” and “To” fields of the email header, rather it inserts the DomainKey signature and related information above the standard email header containing the “From”, “To”, and Subject fields within proprietary head tags that are not part of the SMTP protocol. Moreover, this system utilizes a DNS to store and verify the public key/private key relationships.
One problem with a DomainKey solution to the problem of UBE is that it is not cost effective, for it requires modifying DNS servers by implementing new encryption software on all the world's DNS servers. Such a solution also has an unintended side effect of slowing internet traffic, for all the world's email must be verified via this encryption algorithm.
There remains a need for a simple, yet cost effective way of restricting UBE within an enterprise email environment. The present invention addresses this need.